Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add a MonadBaseControl instance for PropertyT #328

Merged
merged 1 commit into from
Oct 10, 2019
Merged

Add a MonadBaseControl instance for PropertyT #328

merged 1 commit into from
Oct 10, 2019
+42 −0

Conversation

treeowl
Copy link
Contributor

@treeowl treeowl commented Sep 25, 2019 •
edited
Loading

I believe it is possible to write a lawful MonadBaseControl instance
for CofreeT (see this proof), and therefore also for the TreeT, GenT, and
PropertyT types in this package. I can't say for sure whether it
"makes sense", but hey, maybe it does.

@treeowl treeowl force-pushed the monad-base-control-property branch from 8f4623d to a439b09 Compare September 25, 2019 21:08
@treeowl
Add a MonadBaseControl instance for PropertyT
40f38e8 
Under an assumption I believe is reasonable (see
[this issue](basvandijk/monad-control#48) and
[this SO question](https://stackoverflow.com/questions/58105759/monadbasecontrol-laws)
I believe it is possible to write a lawful `MonadBaseControl` instance
for `CofreeT`, and therefore also for the `TreeT`, `GenT`, and
`PropertyT` types in this package. I can't say for sure whether it
"makes sense", but hey, maybe it does.
@treeowl treeowl force-pushed the monad-base-control-property branch from a439b09 to 40f38e8 Compare September 25, 2019 21:27
@jacobstanley
Copy link
Member

jacobstanley commented Oct 10, 2019 •
edited
Loading

Wow this is awesome, I have wanted this for a long time, I didn't think it was possible

@jacobstanley
Copy link
Member

jacobstanley commented Oct 10, 2019 •
edited
Loading

I can't say I really understand how this works, but given it won't break any existing code I say we give it a try. Not sure what would be the best way to check this works.

@jacobstanley jacobstanley merged commit 912f571 into hedgehogqa:master Oct 10, 2019
@treeowl
Copy link
Contributor Author

treeowl commented Oct 10, 2019

Thanks! As I said, I don't really know if this instance is reasonable—the MonadBaseControl laws smell somewhat incomplete to me, so I don't know just what to look for in that regard. But here's hoping!

@jacobstanley
Copy link
Member

I've just been trying this out and it does appear to work, at least for the case of using bracket_ from lifted-base. Time will tell I suppose, but I am about to recommend that people use lifted-base for bracketing from now on given ResourceT has gone the UnliftIO route which we'll never be able to implement.

This has saved us from being stuck on an old ResourceT forever! 🎉 🙏 thanks again

@ocharles
Copy link
Contributor

ocharles commented Feb 5, 2020

Now that we have MonadBaseControl PropertyT is there any need to have TestT?

@jacobstanley
Copy link
Member

That's a good question, it would be interesting to see what happens with lifted-async !

This was the original reason for TestT if I recall:
https://github.com/hedgehogqa/haskell-hedgehog/blob/master/hedgehog/src/Hedgehog/Internal/State.hs#L819-L837

It would be nice to see if the linearize + parallel testing functionality could be made to work with the lookupIx style stateful tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@treeowl @jacobstanley @ocharles